<c:simple-property name="prop2">
<c:property-options>
<c:source target="resource"
linkToTarget="true"
filter="*.jdbc"
expression="type=DomainDeployment"
/>
</c:property-options>
</c:simple-property>
Dependent values
Many parts of the domain model have dependencies on other parts.
Take for example servers and server groups.
Each server belongs to a server group. When creating a new server, the user must provide the server group to put the server in.
The following screen shot is taken from the admin console:
Servers can only be put onto existing server groups, so it would be beneficial to the user to have the property in the RHQ UI not be free-form here, but when there would be a drop-down, that is filled with the content of an "arbitrary" data source.
If server-groups were resources below
Platform->Domain->server-config, this data source could list all server-config.getName() results.
There has been some work done in the past by [~jdob] in JSF-Land
Linking
One of the features of AS 7 is that stuff like e.g SocketBinding Groups are defined on Domain level and then later referenced from e.g. individual server configurations, that take the standard port definitions from a socket binding group (and add an individual offset to them if they run on the same host).
Here is e.g. some configuration of a managed AS server. It should be possible to click on the marked 'main-server-group' to end up at the right place in the tree (which could be on a completely different platform 
) so that the admin can get a quick look at those definitions 
*) A popup showing that node could be also a possibility, but it would be hard to determine what the admin actually wants to do with it.
Use cases
Install a new managed AS in a server group
Dependent values:
-
Host to put the managed server on
-
Server-group to use (op may be executed on a SG, so this may not be needed)
-
Socket-binding group
Deploy a jdbc driver to a server group
Dependent values:
-
Domain content (aka uploaded driver)
-
Server-group to use (op may be executed on a SG, so this may not be needed)
Deploy a data source
-
Server-group to use (op may be executed on a SG, so this may not be needed)
-
deployed jdbc driver on that group (driver name, version)
Deploy an application to a server group
-
Domain content (aka uploaded .war or .ear )
Add a new web connector
-
port (as a config element of a socket-binding-group)
-
socket-binding-group
-
Does this mean we need to first load a socket binding group and then depending
on its value load the list of ports of the group?
-
Have a mod_cluster / mod_jk pick JBossAS servers to use
-
JBossAS instances as target
-
Group of JBossAS as target
Design idea
Basic idea is to let the developer define in the plugin descriptor where the property options come from:
This basically says: go out to the server and ask him to resolve
-
stuff that is of ResourceType=DomainDeployment on any resource (expression)
-
return resources (target)
-
filter the resource names to only return *.jdbc (filter)
This will return a list of
PropertyDefinitionEnumeration
UI-side be treated like the existing
<c:option value="x">Name</c:option>
The "linkToTarget" attribute tells the UI, that when it is showing the configuration (editor) read-only, it should create a clickable link to the target resource (and possibly the config tab in the case that the target is a config).
The next diagram shows an overview of the steps involved.
Expression Language
The above expression is only meant to give an idea. The language used should be something that developers already know like
-
XPath
-
DynaSearch
-
DynaGroups
Agreement is to use Dyna Search – see it's user documentation
Examples for expressions:
-
category=service type=DomainDeployment to find resources that are DomainDeployments
-
type=^Host$ to find Host resources - the ^ and $ are important here, as otherwise this expression also might match "Hostcontroller" or "VHost" type of resources.
If target is configuration, a special form of the expresion comes into play:
-
list=xx:type=SocketBindingGroup – meaning use the part after the colon as search expression and then use a list property with name xx to find the target values
Things to check out
-
Current config definition loading in the coreui module is done by eager loading of resource types and then using the cached configuration definition. That works (mostly) well with the classical
<c:option/>
elements, as they only change when the plugin changes, which is basically not the case for production machines (and if they change, the user can reload the core ui and continue). In the case of dependent values, this is not true, as the values to display need to be generated at the time the editor opens
-
ConfigEditor has in
onDraw()
a check if the configurationDefinition is null and will then call into the server to retrieve it - perhaps this could be changed to always call into the server.
-
Alternatively, put a flag on the top level Configuration object to indicate it dynamic values are used at all and only if this is set (default is unset, so that existing code is backwards compatible), call into the server to get the current version of the config definition.
-
BOM
core/client-api
-
Modify modules/core/client-api/src/main/resources/rhq-configuration.xsd to include the source element
-
adjust org.rhq.core.clientapi.agent.metadata.ConfigurationMetadataParser#parsePropertyOptions to read the source element and add it to the PropertyDefinitionSimple
core/domain
-
Add a new PropertyDefinitionOptionSource entity (TODO: shorter name)
-
Link the PropertyDefinitionOptionSource entity to PropertyDefinitionSimple (1:1)
-
modify dbupgrade.xml and config-schema.xml
enterprise/server/jar
-
ConfigurationMetadataManager: persist new source element
-
ConfigurationManager(Bean,Local,Remote?) add a method to resolve the source dynamically for a given PropertyDefinitionSimple or ConfigurationDefinition
-
TODO what is the best option here.
-
enterprise/gui/coregui
-
Adjust ConfigurationEditor to call into the ConfigurationManager
-
TO be determined when it the best point in time to do this – see discussion above
-
Code
Code is in the dependent-values branch in git
-
Code has only been implemented for Operations so far
-
Code has no optimization yet to check if the callback into the server is needed at all
-
Database table name may need to change
-
Filter element may go away, as the DynaSearch expression can do it name=jdbc will find file names with jdbc in them.
Meeting notes
June 14th, 2011
Actions
Details to what actions refer to are in the minutes
-
ips needs to review this
-
document this, pilhuhn: use case: have a mod_cluster plugin and let it pick either single AS as targets or a group of AS
-
investigate DynaSearch as expression language
-
pilhuhn to flesh out config xsd and parsing of it + persisting of <c:source/> entries
-
pilhuhn to estimate level of effort
-
2 days to understand Search and execute it from a SLSB method
-
1 day to code the callback to examine a configuration definition and load the results
-
1 day to hook up the callback into the UI
*jshaughn/mazz/ips to estimate the ui side
-
Testing
To test the dependent values feature, two things need to come into place
-
the linking code must be present
-
a plugin that has a
<c:option-source/>
element present.